1. Field
This disclosure generally relates to the field of data security. More particularly, the disclosure relates to encryption.
2. General Background
A device, such as a set top box, that receives data may utilize a data encryption key (“DEK”) to protect streams of data or files that move about or are stored, either temporarily or permanently, within the device. Encryption of such data prevents access of the data by unauthorized parties who probe into the device or the data flowing through the device, or who remove and analyze a portion of the device, e.g., a hard drive.
After the device is manufactured, the DEK is utilized to communicate, repair, and/or upgrade the device. The device may utilize public key DEK technology so that the public DEK may be outputted upon a later request. However, public key methods are too slow to handle voluminous or high speed data. Accordingly, symmetric encryption has been utilized. A device that utilizes symmetric encryption utilizes a single non-public key DEK for both encryption and decryption. For instance, if a transmitting chip in a device utilizes a DEK to encrypt data for transmission, then the receiving chip in the device utilizes the exact same DEK to decrypt the data that is received. In order to facilitate operations such as communication, repair, and/or upgrade of the device at a future time, the DEK is stored on a storage medium. This storage medium may be stored in an insecure location that is subject to penetration or access by attackers.
Another current approach establishes a key recovery key (“KRK”) in advance. The KRK is then utilized with a device DEK. However, the combination of the KRK with the device DEK may be inconvenient because a highly protected storage system, e.g., a secure server, should be available both at the time that the DEK is created and at a subsequent time when another device requests the device DEK. Further, the device DEK is sometimes created in a factory environment where maintenance of, or development investment in, a secure server may be burdensome. The long-term maintenance of a DEK server for multiple and unforeseeable future uses may also be inconvenient. Further, the long-term secure storage of a multitude of device DEKs for eventual use may be burdensome. The alternative of utilizing an insecure DEK server is fundamentally inappropriate as DEKs are valuable keys that should be protected everywhere they exist.
Another issue arises if a DEK server is not utilized in order to avoid the aforementioned inconveniences. Accordingly, if a DEK server is not utilized, the DEK is stored inside the device. Devices may vary in design, data storage security levels, and/or robustness. For instance, a device may have a hybrid design in which some data may be stored more securely than other data. As a result, an awkward reliability or failure recovery problem may arise with respect to redundant storage of secure data or related keys, e.g., DEKs. In a scenario where the secure portion, which stores the DEK, of a device fails, a number of current approaches inadequately recover the data protected by the DEK.
One current approach is to store the DEK in an additional location besides the secure portion of the device. This approach is fundamentally problematic because a secure item, e.g., the DEK, is stored in a non-secure storage, which is vulnerable. Such an approach defeats the basic purpose of having secure storage in the first place. The potential solution of having a DEK server as the additional secure location is unavailable with this approach as the assumption is that a DEK server is not utilized.
Another current approach is to forego any attempt at recovering the data protected by the DEK. This approach is also problematic as a fair assumption is that the data protected by the DEK is valuable to one party or another; otherwise, the data would not have been saved in the first place. For example, the data may be valuable to a consumer, who may have a library of encrypted home movies that he or she paid for and does not want to lose. As another example, the data may be valuable to a corporation that may not want to incur the cost of data loss and recovery.
An additional current approach is to encrypt the DEK for such insecure storage. In other words, a KRK is utilized and shared with any party or device that may eventually need to securely communicate with the device or access the DEK-encrypted data stored in the device. This approach attempts to utilize the KRK to protect a device DEK for sharing with another external device. Unfortunately, this approach does not actually achieve anything by itself. Since DEK encryption is itself protected by the KRK, this approach simply transfers the problem to the storage location of the KRK. Encryption does not achieve anything unless the key utilized in encryption is itself protected. This approach does not provide a mechanism to securely store all the encryption keys that are utilized. Accordingly, this approach does not provide adequate security.